: This option takes the user to the maintenance screens for the batches. It lists all the current batches which relate to the current service point. (This means any batch which originated from, passed through or is destined for the current service point.) An overview screen will be displayed:
The display shows each batch number, the current processing status of the batch, the number of items making up the batch, where the items are going from and to, and whether it is “open” somewhere.
: Select a batch and the this option to view the details. See section 812.2.2.
: Select a batch and the this option to to print details of the batch. An input form will be displayed:
: This option allows a note to be added, amended or removed from the selected batch. After selecting this option an input form will be displayed:
: This option allows the batch and all the items comprising it to be marked as suspended.
Processing at the Stack or intermediate service point
The item / stack request is now “in processing” at the service point, and shows this as status for the item.
Processing at the reading room
The item is now marked as available for the reader. The request is set to a status of “Awaiting collection” (and the item status again is the same). The reader is notified, typically by email of the availability of the item.
The display at the reading room is slightly different:
In this case, the “Next” column is clearly always redundant; if “Tables” are defined for the current reading room, then the “Next” column is replaced by a “Table” column and the requestor's table number (if defined) is shown.
If items are to be delivered to specific tables, then the request display screen can be used to display the items that are available at the service point.
These can be listed and / or printed as a guide to delivering the items to the tables.
Notification
When an item is considered to be available (or all items in a group are), then an availability notice is sent by post and/or email according to the contact method defined for the request.
Notification delay
The notification to the reader of the availability of the request can be delayed, typically by a few minutes, according to a setting for the service point. Particularly in the case of a batch checkin, it may subsequently be found that there is a problem with the item – for example, it is simply missing from the box or package. The delay therefore gives staff time to take some kind of action in this.
If the library allows readers to return the items for subsequent consultation, then the parameter Subsequent consultation period for the service point will have a non-zero value.
If this is the case, then on checkin the system will prompt a message asking if the reader wishes to consult the item for a further consultation.
If the item is held for further consultation, it will get a “Held at issue desk” status.
If there is a post-dated request or a queue of reservations, then this message may appear in different forms.
In particular, if there is a queue and the option “Requestor can reserve first” is turned off then the request for further consultation is suppressed. The processing required when the item is to be “held” at the current reading room is described below in section 812.4.3.
Multipart / serials considerations
If the request is for one or more parts of a journal, then the specific parts are recorded in textual form only. In that case, it may or may not be clear whether the part(s) being checked in represent the same items that are required for a reservation or post-dated request.
In this case, the system can determine that there IS a queue for the TITLE – and the system can only display the relevant parts of the requests. The system will pop up such a list.
In this situation, the “reserved” parts may overlap in full or in part with those being returned. The staff member may choose to select one of the displayed requests as being the one to be satisfied; alternatively if one is NOT selected, then the system will assume that the parts being returned do NOT overlap the reservation queue and allow “further consultation”.
If there is a partial overlap, then some parts need to be returned to stacks, some parts may need to be sent to another reading room, and/or some parts retained at this reading room for a reservation. In this case, you must use the option which basically will interrupt subsequent processing.
The returning request is marked as complete, but the subsequent requests are not “current”. Since, by definition, in this context, the system does not HAVE specific details of each piece/part, it cannot keep track. Each part must be “manually” sent to the relevant place and, as appropriate, any requests outstanding manually initiated.
For example, suppose vol 3, 1987 is the one part from the incoming request that is required for a request at the current reading room for vols 2-6, 1987. Then the remaining volumes [2,4,5,6] should be sent to the reading room, and then the whole “Stacks checkin” could be initiated from that location – this would tell the system that all the parts for this request are “ready” – and the reader can be informed, and subsequent processing kicks into life.
Number of parts
If the number of parts comprising a request is set to greater than one, then the system will always prompt the staff member to check that the number of parts returned is correct. Staff may choose to accept or cancel the return of material – but a “partial” checkin (4 out of 5 such items, for example) is not allowed.
On checkin, the item will be returned directly to the stacks IF
· There is no queue of requests for the item
· The setting “Period to keep current if no queue” (in the service point definition in AFO 618) is zero or empty at the reading room.
In this case, the item will be “at the wrong location”; however the regular “ship item to xxx” will be suppressed, because the item was issued via a stack request. If the item was NOT issued via the stack request processing, then the regular transit processing is initiated … the item must be checked back in at its home location using AFO 462.
Otherwise a message reporting on the originating Stack service point will be popped up and the request treated as if it were first checked in for its return to the stacks. If the original location is a combined Stacks/Reading room, then the system will assume that the item is reshelved, as for a regular checkin.
If the route back to the stacks is marked as suspended, then a warning message will be displayed, BUT the processing will continue as if the route were open. The assumption is that the item will be returned somehow.
If a new request is found during processing on the way back to the stacks location OR processing is delayed such that a postdated request is now within its “window”, then a warning can be displayed to indicate this situation. It may actually be easier logistics to simply allow the item to be returned to the stacks and to start again, so there is a system wide option as to whether this feature is enabled.
In such cases, when the request is printed, the full format request is printed.
If there is a reservation or post-dated request for which the item should be held at the reading room, then the item is assumed to be available immediately for the reader.
A request slip may be printed for the item, using the output format defined in AFO 618 – Notice sets for this type. The reader is notified of the availability of the request as for the first arrival of the item at a reading room.
· Document control - Change History
|
Version |
Date |
Change description |
Author |
|
1.0 |
October 2008 |
creation |
|